COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	beeson.not[s85,jmc]	Comments on Beeson's paper on knowledge
C00014 00003	1. The paper mainly describes proposals for expressing strategies
C00015 ENDMK
C⊗;
beeson.not[s85,jmc]	Comments on Beeson's paper on knowledge

Some of these comments are indexed by line numbers of the
message file.  In that case, the title "Logic and Knowledge"
is line 16.

	The paper is written clearly enough, but the formalism
is incompletely developed and seems vague.  Nevertheless, the
following comments can be made.

1. The proposed formalism is too procedural to represent human
common sense knowledge.  The procedures cannot use additional
facts that may become available and relevant if they aren't
built in.  In the restaurant example, suppose Luigi comes to
the door and says that the restaurant opens in five minutes.

2. As long as all the exceptions have to be built into the
rule in advance, there is no significant difference from
putting the negations into the positive part.  I'm not sure
of the role of always having and ELSE part.

The comments about Prolog seem confused to me.  Prolog only allows
the representation of certain information and only allows certain
uses of that information it can represent.

"If logic is to be useful for knowledge representation, a control
structure must be specified."  I don't agree.  Quite different programs
can use the same facts, and we can have facts that we don't as yet
have any way of using.

I don't think default reasoning is correctly characterized in lines
135 and 136.  The point is that many of the C1, C2 etc. aren't even known
when rule is stated and even when the default reasoning is used.
The result of applying circumscription or Reiter default ruless depends
on what facts are taken into account at the time the reasoning is done.
There need be no deliberate decision to ignore known facts; it's just
that the axioms allow for the possibility that more contra-indications
will be discovered later.

lines 143 et seq. raise a point that hasn't been treated in the literature
yet, but I don't agree with the proposed way of looking at it.

The discussion of "something has gone wrong" refers to a different
phenomenon than the one addressed by Reiter and me.

You should look at Winston's treatment of of "if-then-unless" rules.

It seems to me that the "if-then-except" rules are just
ordinary monotonic rules including some case analysis.

The Red Cross rules for poisoning illustrate this point well.
There are no clauses like "do X if you know of no contra-indication";
this would be the essence of a non-monotonic rule.

Actually the unimproved form of the Red Cross rules is closer to
what non-monotonic reason provides for.  Imagine that the patient
is such a fanatical Mormon that he would rather die than drink
the coffee you have available.  The Red Cross didn't think of that
and neither has anyone else till just now.  Genuine non-monotonicity
provides for that but the Beeson rules don't.

The rules for wanting to be in a building also don't provide for
the unexpected.

Prolog programmers do often use "predicates" with side effects in
order to make the program act.  In my opinion they will be sorry,
because it only works when the thinking about action and the
actions themselves behave in a very parallel way, and this often
isn't so.

I confess I didn't understand the Prolog part either, although
I do understand Prolog in general and have written Prolog
programs.

I believe there have been programs which attempt to model their
opponents, and Shannon in the late forties built a machine that
attempted to model its opponent at matching pennies, e.g. it
considered hypotheses like "if tails has come up three times in
a row he will guess heads".  My impression is that no-one had
good enough ideas about modelling the oppponent in chess to
make it seem worthwhile to incorporate them in programs.

Production rules: A key point about actual production rules is that
they contain variables on both sides, and the if-part has to be
matched.

I confess I don't see how the previous Prolog fragment corresponds
to the explanation at line 622.

*** General remark.  The Beeson kind of non-monotonic rule is different
from other forms of non-monotonicity.  Indeed it isn't clear that it
is non-monotonic.  A Beeson rule has ``except if'' clauses.  The main
rule needs a concept of failing.  If it doesn't fail the ``except if''
clauses aren't examined.  If it does fail they are executed.  However,
the full set of ``except if'' clauses are given in advance.  Thus in
the classical bird example, we might have a procedure for building a
bird cage.  Plan it with a top, but if the buyer complains that his
bird is non-flying then remove the top from the plans and build the
cage.  This is the closest Beeson rules come to the usual circumscription
or default logic.  The part about consulting the buyer was thrown in
in order to give the rule a chance to fail.  Also unlike other non-monotonic
systems, Beeson's seems to be specific to systems that take actions,
because that is where the failures come from.  Of course, the actions
don't have to be physical.

beeson.kno[s85,jmc]/647l situations


"For example, in a certain situation in a
restaurant one expects a waiter to be involved.  There would be
a predicate waiter(x); that situation could not be entered until 
one had solved waiter(x), identifying a particular person as the waiter."
line 676 - Does the above mean that we cannot think about waiters
in general?  One can think about the waiter before seeing him, e.g.
deciding that if the waiter is prompt, I'll give a larger than usual
tip.

Is going to the men's room a subsituation?  Complaining about the
fly in the soup?  If not, why the others?

What if someone else pays?

You mention unification on line 763, and yet you require unifying the
variable with a particular person.  If you really mean unification, then
it should be possible to do at least some reasoning with a variable
waiter, and yet you don't mention this possibility.

Is the script really different at a very small lunch counter where the
server and the cook are the same?

I suppose the above are a general grumble about scripts.  If you can
handle extras like complaining or elisions like the waiter and the cook
being the same, why do you need a script?  Schank seems to have moved
somewhat away from scripts toward ``modules'' that interact more logically.

line 796 - Well, I don't agree that everyday life seems to
consist of a succession of scripts; we're more flexible than
that.  When a person thinks ahead, he may imagine a script, i.e.
a definite sequence of events.  It's much more complicated
to keep it variable.  However, the actual mechanisms that
one uses to deal with life are more modular.

line 852 Ah, a fellow MCP.

What we mean by a plan in this context is precisely this:
a sequence of rules R1,...,Rn from the list R, together with a 
sequence of proposition Ai such that 
the following can be proved from R:
Why is a plan taken to be such a sequence rather than a more general
program with conditional gotos?

I'm giving up on the semantics of situations. at line 1033.

line 1322 - I don't believe this simple program will work for
achieving even towers of three blocks.  I think it will get into
some of the loops other programs have.  See the chapter on planning
in volume 3 of the Handbook of Artificial Intelligence.
1. The paper mainly describes proposals for expressing strategies
for achieving goals.

2. The title "Logic and Knowledge" is a misnomer, since only a rather
narrow kind of knowledge is dealt with, and only a fragment of logic
is used.

3. The main innovation (if it hasn't been already proposed by someone
else) is the action rule with exceptions.  The exceptions are ignored
unless the action fails.  This requires a definition of failure and
a way to recognize it.  If failure occurs the exceptions clauses
are successively activated.  They can themselves contain exceptions.